BBS in a Box 3/BBS in a box - Trilogy III.iso/Files/Tele/Internet/ConnectYourBBS Folder/Setting up

Text File | 1993-03-31 | 14.9 KB | 346 lines | [TEXT/MPS ]

IMPORTANT: if you want to send me mail, send it to "[e-mail]"
All other addresses mentioned in this file are for demonstration purposes
only.


This is a first release of a uucp link for Macintosh based fidonet BBS
systems. Goal: to add a news feed to your BBS, to allow your users to read
uucp news groups.

Before you start, you need:

- a BBS (see note 1)
- a Tabby(-compatible) setup (see note 2)
- this package
- UUPC 3.1 (see note 3)


Note 1: you need some experience as a sysop of a Macintosh BBS, wether you're using
TeleFinder, Mansion, Second Sight, Hermes, or whatever. DON'T attempt to install
this unless your BBS has been running for AT LEAST half a year. With YOU as the
sysop.

Note 2: You need a good working knowledge of how Tabby works, with special attention
to the launch.next process (events) and the generic import. What News/Import does
is grab the files transferred in by UUPC and append them to the generic import
file for processing into your BBS. If the above is gibberish to you, put this
package away and re-read the Tabby manuals. Tabby must have been running on
your system (preferrably with a fidonet link) for at least three months
succesfully.

Note 3: You need a working uucp link. UUPC must be installed (by you) and
running - mail MUST have been transferred between your uucp host and your
system. When you've reached that point, you've thoroughly read the UUPC
documentation, you probably bought some of the O'Reilly books, and you've
established a friendly relationship with the system administrator on the
Unix system that has your uucp link.
This software requires a feature from version 3.1.

All this is ESSENTIAL. Do NOT continue if one of the above is not true.



--------------


The UUPC software is not Tabby aware. Therefore, you cannot just place it
in your event chain and expect it to work. 'UUPC Starter' is a small
utility that can sit in any Tabby event chain. It launches UUPC with a
so-called 'call-initiation file' (see the UUPC docs). The best
way to proceed is to create a entry in the UUPC schedule file, and create
a call-initiaion file called 'cron -t30 -quit'
Then, use ResEdit to edit STR resource 130 in UUPC Starter to show the full
pathname of the call-initiaion file.

Make a Tabby Schedule that includes UUPC Starter - and make sure it runs during
the time period you choose in the UUPC Schedule.




Next, open News/Import with ResEdit, and edit STR resource 110. It must
contain the path to your UUPC spool folder. Now, News/Import reads the
'UUPC settings' file first to find this path, but this assumes that this
settings file is in the same directory as News/Import. STR resource 110
is a backup mechanism, in case he UUPC settings can not be found.

Do the same with News/Export.

In News/Export you will also find two STR resources that describe the
node name of YOUR system, and your domainname (usually nodename.UUCP);
Note that these may are interpreted DIFFERENT from those in UUPC settings:
the nodename MUST be exactly the same (since it is used in communicating
with UUPC, the domainname must be the FULLY qualified name. Example:
your node name is 'vamp' - then usually your domainname is 'UUCP' giving
a full address of <user>@vamp.uucp.
However, since it is sometimes necessary to have the uucp node name
something completely different from the mail addresses, the STR resource
that describes the domainname, must have EVERTHING that is to appear
after the @ sign.
If all this sounds confusing, just do the following: in nodename, enter
your nodename, exactly as it appears in UUPC settings. in domainname,
put everything that defines a mail address to your system. Most of the
time, this is your nodename, followed by '.UUCP'
You may wish to discuss this with the system manager at your UUCP host.

In News/Export there are also two important STR# resources that you need
to change. The first one, ID 128, contains any lines that will be appended
to the message header. This is most often used for the 'Organization: ' lines
that describe the organization that owns the machine that originated the
message. Keep this as short as possible.
The second one, ID 129, contains any lines that will be appended after
the body text. This is sometimes used for disclaimer lines like I put in
the distribution copy of News/Export. Keep these lines REALLY short. In
general, personal 'signature' lines are to be kept under three lines, and
general system wide signature lines (which STR# 129 are) are to be avoided
at all, add them only if you have something really important to tell to
the entire world.

News Export stops reading these lines as soon as it encounters an empty one (or
if no more strings exist). Remove the STR# resources if you do not wish to
use them.



Then, create a text file called 'News/Import groups' in your 'Tabby' folder.
(that is the folder where 'areas.bbs' sits). In it, you will specify which
news groups you receive from your uucp host, and to which area's in your
area.bbs file they map. Because fido net conferences have a limitation in
name length, you need to do two things for each news group. Add a line
to your areas.bbs with Tabby Maint (and add a matching thingy to your BBS. For
TeleFinder: add a thread and make sure you add to the setup in TF/Link),
and secondly, add a line with the same group number to 'News/Import groups'.
An example areas.bbs and 'News/Import groups' have been shipped with this
package. Look at them.

The format of each line in 'News/Import groups' is:
number<tab>newsgroupname<tab>newsfeed<return>

The 'number' is the same number as in the areas.bbs file.
The newsgroup name is the full name of the newsgroup, for example
'comp.sys.mac.programmer' or 'alt.swedish-chef.bork.bork.bork'

Remeber that newsgroups are always written in lowercase on the internet.
Newsgroupnames are CASE SENSITIVE, so make sure the entire News/Import groups
file is in lower case.


the 'newsfeed' is the name of the system you get this news group from and
want messages to go to. Note that this software can only exchange a news
group with one single host - it is not possible to SEND news in one group
to more hosts (it is possible to RECEIVE the same group from more than
one host, though. Just enter the name of the system you want news to go to
when entered on your BBS)

Note: you MUST add at least the following two groups: 'junk' and 'control'.
They will contain control messages (ignored in this release) and messages
that do not belong to any known group. the newsfeed entries for those
groups must be 'all'

(the name 'News/Import groups' is a bit misleading, as News/Export also
uses this file...)


Next, add News/Import to the event chain, after 'UUPC Starter' and before the
import into your BBS. Try it out by launching News/Import by hand, and read
the Tabby Log to check for errors..

'Booster' is an application that does the same as UUPC Starter, in a different
way. It also needs ResEdit to set up. Try them both, to see which one does
what you want. Booster was written by Chris Silverberg, because his BBS does
not run Finder (but runs At Ease), and UUPC Starter requires the Finder...



Finally, ask your uucp host to switch on news processing for you, and specify
which news groups you want. Also, tell him that he needs to make a special
entry in 'explist' in his /usr/lib/news directory (all this assumes he's
using cnews). Tell him to add the following entry:

<yoursitename>   10000 20   batcher  nocomp  viauux

(This will tell cnews to send news UNCOMPRESSED. Compression is scheduled for
a future release of News/Import)


When you've succesfully transferred news this way, add News/Export to every
even chain that includes export of message from your BBS to Tabby. Add
it to a point in the chain just AFTER the export from your BBS system. This
will probably be very early.



Note that, by default, incoming news messages will only get written to Generic
Import for import into your BBS system. If you want to export news messages
to, say, your point systems, you need to tell News/Import that it should also
write all messages it processes to the Generic Export file. You can do that
by putting a 'Y' in the STR  resource 130 in News/Import.

Long time users of Tabby will notice a potential conflict here. This is the normal
process:

export of new messages entered on BBS to Generic Export -> News/Export prepares
them for UUPC -> UUPC call to host  -> News/Import writes new messages from UUPC
to Generic Import  -> import into BBS

With a 'Y' in STR resource 130, News/Import will also write to Generic Export,
which introduces the risk that News/Export will prepare those message for
transmission to your UUPC host - this would mean sending all message received
from the host back to it, with a terrible 'dupe loop' as a result. To prevent this,
News/Export will look at the last line of each message in Generic Export. If it
reads '--- News/Import vX.X' it will NOT export the message to UUPC. News/Import
marks each message it processes in this way.



Technical Notes on exporting messages:
(this discussion assumes that the host you exchange message with is a unix box.
Since UUPC emulates this rather well, you should not be concerned if you
happen to have a UUPC host rather than some unix box)
(if you don't really care about the inner workings of News/Export and UUPC, you
can skip this part)

On export of each message, three files are created in the uucp spool directory.

The first is called "D.xxxx0000" Where xxxx stands for YOUR node name, and 0000 is
a message count (this message count increases for each message exported, and
wraps back to zero at 9999 - it is recorded in your Tabby folder in the file called
"News/Export count" - also all three files belonging to the same message have the
same count)

For example, a file from my node (which has the uucp name "vamp" and is part of the
domain "fourc.nl") could be called
"D.vamp0027"

In this file, you will find the message text, with on top, seperated by linefeeds
instead of normal returns, the message header - it describes who sent the message,
what the subject is, what newsgroup it belongs to, etc. It has linefeeds because that's
how the unix host expects it. If one replaces the linefeeds with returns, the header
might look like this:

Newsgroups: comp.sys.mac.programmer
Path: vamp
Date: Mon, 15 Mar 1993 21:06:43 -0800 (PST)
From: John Sinteur <[e-mail]>
Subject: Re: process info problems
Message-Id: <[e-mail]>

The path line lists all systems that processed this message - in this case only the
site that generated the message. The message ID is year, month, date, hour, minute,
and the message count mentioned above. This could allow for some tracing and debugging.
The from line lists the name of the sender, and his or her return address in internet
style.


The second file is called "C.yyyy0000" where yyyy is the uucp host that the message
is to be sent to. The 0000 is the message number again. In this example, we
will use the file "C.fourcnl0027"

This file is a 'command' file - it contains commands for UUPC. Usually, it
contains two lines, seperated by linefeeds, like this:

S D.vamp0027 D.vamp0027 usenet - D.vamp0027 0666 usenet
S D.fourcnl0027 X.fourcnl0027 usenet - D.fourcnl0027 0666 usenet

These are two 'send' commands. The first line sends ('S') the file called
D.vamp0027 from the spool folder to the host, and names it D.vamp0027 on the
host. Unix like features like owner (usenet) and mode (0666) are set. As a
Mac user, you don't really have to worry about that. This first file contains
the message text, as we saw above. The second line sends the file called
D.fourcnl0027 to the host, and names it X.fourcnl0027 there. Again, unix
priviliges are set, but the interesting bit here is that the filename on
the unix host starts with X. For UUCP on the host, this is a signal that after
the connection is through, it should read this file and execute any command in
it.

As you noticed, the lines both start with 'S' (for Send). 'R' and 'X' are
also possible, but are not covered here. They mean 'receive' and 'execute'.

To be exact, the line has the following format:

S srcfile trgtfile user opts datafile mode notify

where the following parts are defined:

• srcfile is the fully-qualified pathname of the source file

• trgtfile is the fully-qualified pathname to which the file is
to be copied on the target system

• user is the sending user's login name (in this case always 'usenet')

• opts options, preceded by "-"

- c send directly from srcfile. If absent, send from copy
of file in spool directory, name given by datafile, and delete copy after
transferring; in this case srcfile is informational, providing the file's
original name.
- m notify sender by mail when copy is completed
- n notify user notify on target system when file arrives

If no options are present, a hyphen appears here as a placeholder.

• datafile if "c" option present, "D.0"; if "c" absent, gives the
name of the data file in the spool directory for uucico to send.

• mode is the Unix-style file protection mode (in octal) to be
given to the new file

• notify is the name of a user on the target system; present only
if "n" option present

-----


The execute file is the third file, and it is called D.yyyy0000 where yyyy is
the uucp host that the message is to be sent to. The 0000 is the message
number again.

When the line feeds are again converted to returns to allow for easy reading,
the contents look a bit like this:

U usenet vamp
# return status on failure
Z
# use sh to execute
e
# return address for status or input return
R sysop
# job ID for status reporting
J 0027.2
F D.vamp0027
I D.vamp0027
C rnews


The lines starting with "#" are comments. As you may note, the 'return adress'
is 'sysop'. Should something disastrous happen, the unix system will attempt to
mail this user on your system. Since most systems define a user called 'sysop',
I put this in as a default (in my experience, systems that start out with a user
'sysop' will usually add one within the first couple of weeks of operation - users
tend to expect a 'sysop')
The really interesting bit is the line that defines the command to execute:
C rnews
Usually, the number of commands a system is allowed to execute in this manner is
limited to simply two: 'rnews' and 'rmail' (for sending news and mail) and only
on rare occasions are other commands possible.

To get technical again:

C command to be executed
I file name for command input
O file name for command output
F file required to be present before running command; optional
     second argument gives name for the file at execution time
R name of user who issued request (relative to the host named on the U line)
U second arg is name of host that passed this X. file to me;
   first arg is a user name on that host (overridden by R line)
Z send status notification (and error output) if command failed
N send no status notification if command failed
n send status notification if command succeeded
B return command input on error
e requests command be processed with sh(1)
E requests command be processed with exec(2)
M return status info to the named file on the requesting host
# comment line